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MULTICAST OVER XJNICAST IN A NETWORK 

FIELD OF THE INVENTION 

S The present invention relates generally to network communications and, in particular, 

to a method and apparatus for communicating broadcast/multicast data via imicast 
sessions/connections. The invention is particularly suitable for implementation in a wireless 
Local Area Network (WLAN) system operating in accordance with the Institute of Electrical 
& Electronics Engineers* (IEEE) 802. 11 standards. 

10 

BACKGROUND OF THE INVENTION 

The context of the present invention is the family of wireless local area networks or 
WLANs based upon the IEEE 802.11 standards, which define intermediate devices (IDs) 

15 such as access points (APs), bridges, routers and brouters that provide access for mobile 
devices and to other networks, such as hard-wired local area and global networks, such as the 
Internet. Wireless receiving points utilized in access broadcast video streaming may include a 
set top box in a simple system, whereas in commercial rebroadcast system a transcoder 
/multiplexer/demultiplexer or TMD may operate in conjunction with a local video server. In 

20 receiving Internet data, a common gateway operating in a conventional Internet 
Protocol/Transmission Control ProtocolAJser Datagram Protocol (IP/TCP/UDP) protocol 
may be utilized. 

Conventionally, the IEEE 802.11 based architecture is comprised of several 
components and services that interact to provide station mobility transparent to the higher 

25 layers of the network stack. The EBEE 802.11 based network defines a station as the 
component that connects to a wireless medium and contains the fimctionality of the IEEE 
802.1 1 protocols, that being MAC (Medium Access Control), PHY (Physical Layer), and a 
connection to the wireless media. Typically, the IEEE 802.11 protocols are implemented in 
the hardware and/or software of a network interface card (NIC). 

30 The IEEE 802.1 1 standards also define a Basic Service Set or BSS, which is regarded 

as a basic building block in WLAN architecture. The BSS consists of a group of any number 
oriD stations that conununicate with one another. In an independent BSS, the mobile 
s t ations coimnuni cate directly widi each other. In an infirastructure BSS, all stations in the 
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BSS communicate with die ID and no longer communicate directly with the independent 
BSS, such that all frames are relayed between stations by the ID. 

A station could be a laptop PC, handheld device, or an AP. Stations may be mobile, 
portable, or stationary and all stations support the IEEE 802.11 station services of 

5 authentication, de-authentication, privacy, and data delivery. 

If the broadcast or multicast originator is a mobile terminal, broadcast or multicast 
data are first transferred from the mobile terminal to the ID in a unicast transmission. In 
general, a broadcast transmission is a transmission from one to all; a multicast transmission is 
a transmission from one to many; and a unicast transmission is from one to one. Hereinafter, 

10 broadcast and multicast will be used interchangeably. According to the IEEE 802.11 
specifications, the broadcast/multicast message may be distributed into the BSS by the ID. 
Regardless of the length of the fi:ame, no RTS/CTS exchange can be used. In addition, no 
ACK is permitted to be transmitted to flie ID by any of the recipients of the 
multicast/broadcast firame(s). There is no MAC-level recovery on broadcast or multicast 

1 S frames sent from the ID. 

Video transmissions - in particular real time transmissions - require 
broadcast/multicast transmissions over a network, e.g., over a WLAN. However, 
broadcast/multicast transmissions suffer from an inherent lack of an error correction 
mechanism. When a data packet is sent to a group of receivers (broadcast/multicast), it is 

20 extremely difficult, if not impossible for the transmitter to manage the retransmission 
protocol for each receiver. 

Several mechanisms exist to overcome the data packet loss in a network, in particular 
in a WLAN, such as automatic forward error correction (FEC), multicast automatic repeat 
request (ARQ) etc. All of these mechanisms, however, suffer &om significant added 

25 complexity and limitations in certain network products. For example, some WLAN 
intermediate devices like an Access Point (AP) or a bridge, where bridge and/or AP are used 
herein to include router and/or brouter or any device having equivalent fimctionality, have an 
inherent limit in the transmission rate for WLAN multicast data packets on the premise that 
multicast quality should be limited by the client , e.g., mobile terminal with the poorest 

30 reception (i.e., the client that is farthest away from the ID). Such a limitation dictates that 
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even if a client is close to the ID there is no possibility for any QoS upgrade of the multicast 
quality. 

SUMMARY OF THE INVENTION 

The present invention offers network multicastA)roadcast services using unicast 
sessions thereby profiting firom the ARQ-based error correction mechanism used for a unicast 
connection to enhance the quality of multicast/broadcast conmiunications to neighboring 
users. If a unicast session exists that uses ARQ*based error correction, then neighboring users 
can listen in on the unicast session and profit fit>m the ARQ mechanism without requiring 
any additional unicast sessions to be initiated and maintained. Thus, normal unicast 
mechanisms can be leveraged to provide multicast/broadcast services without complex FEC 
or multicast ARQ schemes. Additionally, it is possible to accommodate a plurality of 
transmission rates, e.g., 1 Mbps, 2 Mbps, 5.5 Mbps and 11 Mbps. Hereinafter, the terms 
session and connection will be used interchangeably. 

This plurality of transmission rates also addresses the near/far problem. The near/far 
problem is the term used to indicate that the throughput rate is lower at the edges of the cell 
(far) and higher closer to the intermediate device (near) and that the error correction schemes 
are, therefore, also different. The UDP traffic is assumed to be broadcast/multicast (e.g., 
video multicast). In the present invention, the UDP broadcast/multicast data packets are 
encapsulated into Ethernet frames for transmission via unicast sessions/connections. 

A method is described for receiving a multicast in user devices in a network issuing a 
request to join a multicast group, identifying multicast data packets associated with the 
multicast group, monitoring transmissions of the multicast data packets to determine whether 
the identified multicast data packets are being transmitted in an already established unicast 
session and establishing a unicast session and processing multicast data packets if an already 
established unicast session does not exist. A method is described for receiving a multicast 
transmission in user devices in a network establishing a unicast session with a dedicated 
terminal, identifying multicast data packets associated with a multicast group, monitoring 
transmissions of the multicast data packets and processing the multicast data packets by the 
dedicated terminal. 
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Additionally, an apparatus is described for accq)ting a request to join a multicast 
group, for identifying multicast data packets associated with the multicast group, establishing 
a unicast session, for encapsulating said multicast data packets in a unicast frame and for 
forwarding the unicast fi^me via the unicast session. Additionally, an apparatus is described 
5 for establishing a unicast session with a multicast-to-unicast converter, for identifying 

multicast data packets associated with a multicast group, for encapsulating the multicast data 
packets in a unicast frame and for forwarding the unicast fi-ames via the unicast session. 

A method and apparatus are described for receiving a multicast/broadcast in user 

10 devices in a network, comprising receiving, by an intermediate device (ID), a request from a 
first user device to join a multicast group, identifying multicast/broadcast data packets 
associated widi the multicast group, monitoring transmissions of the multicast/broadcast data 
packets &om tiie ID, by the first user device, to determine whether the identified 
multicastA>roadcast data packets are being transmitted between the ID and a second user 

1 S device in an already established unicast session/connection between the second user device 
and the ID, processing the multicast/broadcast data packets by the second user device, if the 
second user device is in the already established unicast session/connection between the 
second user device and the ID and establishing a unicast session/connection between the first 
user device and the ID and switching to normal mode and processing multicast/broadcast 

20 data packets by the first user device, if one of the second user device is not in the already 
established unicast session/connection and the first user device is no longer in a coverage 
area for receiving transmissions between the second user device and the ID. Further, testing 
to determine if the user device is still active. If the user device is still active then continuing 
to receive and process multicast data packets by the user device. If the user device is not 

25 active then selecting a new user device by the ID and establishing a unicast 

session/connection with the newly selected user device. The newly selected user device 
switching to normal mode and receiving and processing multicast data packets via the newly 
established unicast session/connection. 

In an alternative embodiment that supports multiple multicast transmission rate and 

30 the uses of dedicated terminals, a wake-up message is used to determine if the dedicated 

terminal is still active. Also since at least one dedicated terminal is used, there is no necessity 



wo 2005/036818 



PCT/US2004/032963 



5 

to wait for an IGMP request for transmission of multicast packets to take place. Once a 
unicast session/connection is established with the at least one dedicated terminal then 
transmission of multicast data packets (encapsulated as Ethernet frames) occiirs. Other user 
devices that join the multicast group can simply listen in on the unicast 
session(s)/connection(s). Multiple unicast sessions/connections support multiple transmission 
rates and may be established by establishing multiple imicast sessions between the ID. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention is best understood with reference to the Detailed Description of the 
Preferred Embodiments and the drawings where: 

FIG. 1 illustrates an exemplary digital video and audio system suitable for 
implementing the present invention; 

FIG. 2 is a block diagram of the present invention; 

FIG. 3 is a block diagram of an exemplary system in which the present invention may 
be implemented; and 

FIGs. 4A and 4B are flowharts illustrating the methods of the embodiments of the 
present invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

FIG. 1 illustrates an exemplary digital video and audio system suitable for 
implementing the present invention. At the head end a multiple video and audio content 
stream is converted into a digital format (typically in accordance with the MPEG-2 standard) 
and transmitted via, for example, satellite to a receiving dish, or other suitable means, which 
is. attached to a leceiver referred to as a set top box or other suitable means such as a TMD. 
U.S. Patent 6,510,519, describes a representative system utilizing a head end and a set top 
b ox including timers, de-modulators, decoders, transport de-multiplexers, microprocessors, 
program memories, video picture memories, MPEG video decoders, displays, and smart 
cards. Most digital broadcast system data streams are encoded and scrambled for security 
purposes~at-a transmitter; once decryption and decoding occur at a receiver, the system builds 
a video composite picture in memory and displays the desired picture synchronized with its 
audio component on a monitor, hi addition to descrambling the program, generally, further 
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authorizations are provided to insure that the particular receiver has been enabled to receive a 
program or a set of programs. 

As further illustrated in FIG. U TMD operating in conjunction with a local video 
server may be designed and configured to further commimicate with a video LAN and a 

5 wireless AP, which in the illustrative example provides down line receivers with 
demultiplexed video and audio transmission streams including synchronized signals 
necessary for the transmission of the video and audio content. 

The present invention provides error correction for multicast sessions over a WLAN 
requiring only one WLAN unicast session/connection. In a public hot spot like an airport, a 

10 restaurant or a lobby of a hotel, it is possible to locate an intermediate device in such a way 
that the characteristics of the wireless channel are nearly identical for a group of user devices 
iising for example, mobile terminals/mobile devices (MTs/MDs) co-located or in sight of 
each other. If, at least one imicast session/connection exists between the JD and one user 
device, then due to the inherent usage of the MAC ARQ mechanism, the quality of the 

IS transmission is good. The other user devices are then able to capture the traffic related to the 
unicast session without the need to effectively communicate with the ID. That is, additional 
unicast sessions need not be initiated or maintained. 

A video source communications is broadcast towards an ID from e.g., a video server. 
It is assumed that the video source is a multicast/broadcast source where the destination IP 

20 packet discerns the broadcast/multicast IP address Mai of the multicast group Ml. The ID 
blocks the packets until a user device expresses its intention to receive the 
broadcast/multicast data packets. The user device Tl initiates an application Al that is ready 
to process incoming data packets relative to the multicast group Ml. Tl sends an IGMP 
message towards the network (thus, to/through the ID) that is a request to be associated with 

25 the group Ml. The ID receives the IGMP message and since this user device is the first 
element requesting association with the multicast group Ml, the ID forwards the IP multicast 
data packets using as the MAC destination address (the MAC address of the user device) Tl. 
Normally, a multicast IP address is converted to a multicast Ethernet MAC address. An IEEE 
802.11 user device processing a packet, determines whether the destination address is a 

30 multicast address. If the address is a multicast data packet then the user device cannot use the 
MAC ARQ mechanism. In the present invention, the multicast/broadcast data packets are 
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encs^sulated in Ethernet frames for transmission via a unicast session/connection. The inner 
IP data packet contains die imchanged IP multicast group address Mai. The outer IP data 
packet contains the unicast destination address of user device TL The user device Tl 
receives the IP data packets. In case of a transmission error, retransmission is possible 
through the IEEE 802. 1 1 MAC ARQ mechanism. 

A second terminal T2 initiates an application A2 that requests association with the 
same group Ml. T2 first listens (T2 needs then to switch its wireless network interface card 
(NIC) into monitor mode in which all packets (whatever the destination address) are captured 
by the NIC and delivered to the upper layer (usually the driver)) by the channel dedicated to 
the video streaming and searches for a session carrying IP data packets for which the 
destination address corresponds to the multicast group address Mai. Because such packets 
exist, T2 remains in monitor mode listening to the corresponding data packets. In case of 
packet loss, based on the assumption that tfie error distribution pattern is very close between 
neighbor user devices, user device T2 also receives the repeated packets sent from the ID to 
Tl. 

In the event that the unicast session is broken/ended because the user device 
disassociates (leaves the cell), there is a need for a mechanism to select/designate/locate a 
new unicast session user device (coimterpart) for the ID. Once a new user device is 
located/chosen/designated, the ID forwards the video related data packets in \micast mode 
(i.e. the destination MAC address corresponds to the new selected unicast coimterpart) to the 
newly selected/designated/located user device. The newly designated user device would 
normally be in monitor mode listening to all the incoming data packets relative to the IP 
multicast group (Ml). Once tiie newly designated user device detects/determines that the data 
pack^ are addressed to itself (by scanning the IEEE 802.11 header), the user device 
switches to the normal mode (i.e. non-monitor mode) and processes the data packet normally. 
Tnis switching should take place as quickly as possible in order to reduce the adverse visual 
efF^rtg that could be triggered by any delay in the switching. 

The present invention can be adapted for other radio wireless LAN technology as 
Hiperlan2. The present invention can also be Sidapted for cable networks and 3G cellular 
networks that support broadcast services. An ARQ mechanism at the MAC layer and the 
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ability to switch between monitor mode and nomial mode is all that is required for the 
present invention to operate with other wireless LAN technologies. 

In an alternative embodiment that addresses the problem of the user device that is 
communicating via the imicast session leaving the cell, a dedicated teraiinal could be 
designated. The only function of the dedicated terminal is to run the MAC protocol. The ID 
establishes the vmicast session with this dedicated terminal. Other/additional dedicated 
terminals may be located elsewhere in order to handle the multi-rate capability of the WLAN 
radio technology or to provide a back-up in the event that the first dedicated terminal fails. 
Several schemes are known in the art to detect failed terminals and switch to a back-up 
terminal. 

The present invention has been described above as embedded in the ID. However, in 
an alternative embodiment the present invention may be implemented outside of the ID. 
Considering the ID a bridge, the multicast-to-unicast converter needs to be located on the 
same Local Area Network (LAN) as the ID. The multicast-to-unicast converter can, however, 
be located in the video server if the video server is imique or the multicast-to-unicast 
converter can be located in a separate and independent device. 

The multicast-to-vmicast converter is configured with two interfaces: one connecting 
the converter with the ID of the network and the other interface connecting the converter 
with the video server(s). The multicast-to-unicast converter Amotions in the following 
manner: 

• The converter blocks multicast/broadcast data packets coming fiom the video servers 
until an IGMP request is detected. 

• Upon receipt of a first IGMP request received firom the network via the ID, the 
converter forwards the corresponding IP multicast data packet encapsulated into 
unicast Ethemet frames (for a unicast session) with a destination address 
corresponding to the source address of the received IGMP packet. 

• A drawback of an external multicast-to-imicast converter is that, being outside the ID, 
the converter has no knowledge of the MAC and does not know whether flie imicast 
terminal is still available (i.e., if ARQ is running with that terminal or not). Only the 
ID has that knowledge. A solution to the problem is to use one or more (at least one) 
dedicated terminals known in advance by the converter. The dedicated terminal that is 
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involved in the unicast MAC session with the ID sends a wake-up message regularly 
to the converter. If the converter does not receive such message after a predetermined 
time then the converter forwards the multicast/broadcast IP data packets to another 
dedicated terminal. 

S In a WLAN that offers multicast services, it is desirable to have multiple multicast 

sessions with different levels or qualities of service (QoS). For clients that can get clear 
signal from the WLAN ID, the multicast quality can be higher and at a higher rate. For 
clients that are, in general farther from the ID and have poor reception, only a lower rate will 
be supported. For example, in DEEE 802.11b based WLAN, 4 different modulation schemes 

10 and thus rates are supported. The supported rates are 1 Mbps, 2 Mbps, 5.5 Nfbps and 11 
Mbps. Although not defined in the standard, some wireless LAN IDs limit the transmission 
rate for any multicast sessions to a fixed low rate on the premise that multicast clients may 
have drastically different reception quality and a low rate that can accommodate most clients 
should be chosen. There are no such restrictions on unicast sessions/connections. In the 

15 present invention, since multicast services are offered using unicast sessions/coimections, 
multiple multicast (actually unicast) sessions each with different rates are easily supported. 
These rates are not statically allocated, but rather depend on whether there are clients that 
require and can support such rates. For example, if all clients are close to the ED, a multicast 
session with 5.5 Mbps may be supported. But if some clients move farther away from the ID, 

20 a new "multicast" (actually a unicast) session at a lower rate e.g., 1 Mbps rate, may be 
initiated. 

FIG. 3 is a block diagram illustrating a computer system 100 to which the present 
invention may be applied, according to an illustrative embodiment of the present invention. 
The computer processing system 100 may be embodied in a mobile device used to access a 
25 cellular network or a WLAN. The computer processing system 100 includes at least one 
processor (CPU) 102 operatively coupled to other components via a system bus 104. A read 
only memory (ROM) 106, a random access memory (RAM) 108, a display adapter 1 10, an 
I/O adapter 112, a user interface adapter 114, a sound adapter 170, and a network adapter 
198, are operatively coupled to the system bus 104. 
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A display device 116 is operatively coupled to system bus 104 by display adapter 
1 10. A disk storage device (e.g., a magnetic or optical disk storage device) 1 18 is operatively 
coupled to system bus 104 by I/O adapter 1 12. 

A mouse 120 and keypad/keyboard 122 are operatively coupled to system bus 104 by 
5 user interface adapter 1 14. The mouse 120 and keyboard 122 are used to input and output 
information to and from system 100. 

At least one speaker (herein after "speaker") 185 is operatively coupled to system bus 
104 by sound adapter 170. 

A (digital and/or analog) modem 196 is operatively coupled to system bus 104 by 
10 network adapter 198. 

FIG. 4 A is a flowchart of the functions performed by a multicast-to-unicast converter 
in accordance with the present invention. In this embodiment of the present invention, the 
multicast-to-unicast converter is assxuned to be embedded in the ID. The converter blocks 
multicast data packets coming from the video server(s) until a first IPMG request is received. 
IS Once the first IPMG request is received, then multicast data packets received fix)m the 
network are encapsulated into Ethernet frames (for a unicast session) with a destination 
address corresponding to the source address of the received IGMP request. A test is then 
made periodically to verify that the \iser device is still active. If the user device is still active 
(the user device has not left the cell or failed) then multicast data packets continue to be 
20 forwarded. If, however, the user device is not still active (the user device has failed or left the 
cell) then a new user device must be located/selected/designated and the multicast data 
packets will be forwarded to the newly selected/designated/located user device. The user 
device will receive and process the data packets once the user device switches from monitor 
mode to normal mode. 

25 FIG. 4B is a flowchart of the frmctions performed by a multicast-to-unicast converter 

external to the ID. The main difference is receiving wake-up (watchdog timer) message or 
not. In this embodiment of ttie present invention, the multicast-to-unicast converter is 
assumed to be external to the ID. A dedicated terminal known in advance to the ID is used 
for the unicast session for receiving and processing multicast data packets. The multicast data 

30 packets encapsulated into Ethernet fimies (for the unicast session) are forwarded to the 
dedicated terminal. A test is then made periodically to verify that the dedicated terminal is 
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still active (wake-up message received). If the dedicated terminal is still active (tiie dedicated 
temiinal has not failed - the wake-up message has been received) then multicast data packets 
continue to be forwarded. If, however, the dedicated terminal is not still active (the dedicated 
terminal has failed - the wake-up message has not been received) then a new dedicated 
S terminal must be selected/designated and the multicast data packets will be forwarded to the 
newly selected/designated dedicated terminal. The newly selected dedicated terminal will 
receive and process the data packets once the newly selected dedicated terminal switches 
from monitor mode to normal mode. A dedicated terminal is used in this embodiment of the 
invention because the muIticast-to-\micast converter would not otherwise have any 

10 knowledge of the MAC address since it is external to the LAN. A dedicated terminal would 
also be used when it is desirable to support multiple multicast (actually unicast) 
sessions/coimections having different transmission rates. 

It is to be imderstood that tiie present invention may be implemented in hardware, 
software or firmware or any combination thereof. It is to be further understood that, because 

IS some of the constituent system components and method steps depicted in the accompanying 
figures may be implemented in software, the actual coimections between the system 
components (or the process steps) may differ depending upon the manner in which the 
present invention is programmed. Given the teachings herein, one of ordinary skill in the 
related art will be able to contemplate these and similar implementations or configurations of 

20 the present invention. 

It is to be understood that the form of this invention as shown is merely a preferred 
embodiment. Various changes may be made in the function and arrangement of parts; 
equivalent means may be substituted for those illustrated and described; and certain features 
may be used independently from others without departing from the spirit and scope of the 

25 invention as defined in the following claims. For example, although the invention is 
desenfoed-in the context of IEEE 802.11 based WLANs, it is to be imderstood that the 
invention may be applied to structures based on other wireless LAN standards and formats 
that-utilize the principles described above. 

30 



